COW基本定义
写入时复制（Copy-on-write，简称COW）是一种计算机程序设计领域的优化策略。其核心思想是，如果有多个调用者（callers）同时要求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的（transparently）。此作法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被创建，因此多个调用者只是读取操作时可以共享同一份资源。
COW的处理过程中需要维持一个为读请求使用的“指针”，并在新数据写入完成后更新这个指针以提升读写并发能力。因此，COW也间接提供了数据更新过程中的原子性。在保证数据的完整性同时还保证了一定的读写效率，下面让我们针对一些采用COW的场景看看处理流程上的差异。
使用场景
在文件系统中的应用
数据的备份或者复制至少处于硬件(硬盘)和操作系统两个层级。硬件备份一般使用RAID0-10的方案，保护硬盘中的数据安全；操作系统中则使用Snapshot(快照)技术来维持数据的安全和有效。人们一直采用数据复制、备份、恢复等技术来保护重要的数据信 息，定期对数据进行备份或复制。由于数据备份过程会影响应用性能，并 且非常耗时，因此数据备份通常被安排在系统负载较轻时进行(如夜 间)。另外，为了节省存储空间，通常结合全量和增量备份技术。为了解决性能和持续运行的问题引入了Snapshot，Snapshot的实现又主要分为split mirror、changed block和current三大类，具体实现方式中会有部分依赖COW技术。
COW快照写操作基本流程：
1. 读取原始数据
2. 把原始数据复制到一块新的未被使用的快照空间
3. 把新数据写入到原始位置
基本的处理流程比较简单，由于只复制了被更新部分数据，整个流程处理十分快速。在写操作的同时所有的读请求都是通过逻辑访问所有原始数据，包括被拷贝到新空间的部分，而不会读到正在写入的数据。
尽管COW简单高效，但是也存在一些问题，比如：
1. 数据复制过程带来了更多得io消耗(实际应用中可能更倾向于使用Redirect-on-write)；
2. 快照只保存了被修改部分的数据，并没有完整的数据备份；
3. 如果新写入的数据超过旧数据占用的空间也会导致一系列复杂处理，最终导致快照失效；
4. 只能应对单一的数据处理，多重复杂结构数据的修改需要特殊处理
除了COW，常见的快照技术还有Log-structuredfilearchitecture（日志文件架构）、Copyonwritewithbackgroundcopy（克隆快照）、Continuous data protection（持续数据保护）、Split Mirror（镜像分离）和Pointer Remapping（指针重映射）等等，特性对比参见下表
| 镜像分离 | 指针重映射 | 写时复制 | 日志文件 | 克隆快照 | 持续数据保护 | |
|---|---|---|---|---|---|---|
| 快照是否依赖源数据卷 | NO 镜像包含完整的数据副本 | YES 未变化的数据从源数据卷访问 | YES 未变化数据从源数据卷访问 | YES 未变化数据从源数据卷访问 | ONLY 仅在后台拷贝未被完成时 | YES 除了包含源数 据副本实现外 |
| 空间效率 | NO 要求源数据卷相同容量存储空间 | YES 大多数据情况下要求变化数据存储空间 | YES 大多数据情况下要求变化数据存储空间 | YES 要求变化数据存储空间 | NO 要求源数据卷相同容量存储空间 | YES 存储空间需求取决于保存变化数据的数据和频率 |
| 源数据卷系统CPU和I/O负载 | LOW/HIGH 镜像分离后低，分离前数据同步高 | HIGH/NONE软件型快照高，硬件型快照无 | HIGH/NONE软件型快照高，硬件型快照无 | HIGH对写操作进行日志时高 | LOW一般由存储子硬件执行 | 具体实现相关 |
| 源数据卷写负载 | NONE写负载发生在分离前 | NONE写直接重定向至新块 | HIGH首次写产生额外写负载 | HIGH写操作必须进行日志 | HIGH拷贝完成前的首次写产生写负载 | HIGH每次写操作导致相应的写操作 |
| 逻辑数据错误保护机制 | YES数据必须从镜像卷拷贝，变化没有记录，速度较慢 | YES数据变化可以回滚或者同步至源数据源 | YES数据变化可以回滚或者同步至源数据源 | YES数据变化可以回滚 | YES可以反向建立快照，由于仅复制变化数据块，速度较快 | YES数据变化可以同步至原始数据副本 |
| 源数据卷物理介质故障保护机制 | YES镜像卷是完整副本 | NONE有效源数据卷必须存在 | NONE有效源数据卷必须存在 | NONE 有效源数据卷必须存在 | YES后台复制完成后完全保护 | 具体实现相关 |
软件和web系统中也经常出现COW的使用场景，比如数据备份和并发环境下的读写性能力提升。
软件和web系统中的应用
linux中创建轻量级的子进程
我们都知道，进程是操作系统中比较昂贵的资源，它具有自己的数据和程序。
传统方式下，fork()函数在创建子进程时直接把所有资源复制给子进程，即：正文段块，数据段块，堆块，栈块。这种实现方式简单，但是效率低下，而且复制的资源可能对子进程毫无用处。linux为了降低创建子进程的成本，改进fork()实现方式使用COW技术创建子进程。当父进程创建子进程时，内核只为子进程创建虚拟空间，父子两个进程使用的是相同的物理空间。只有父子进程发生更改时才会为子进程分配独立的物理空间。
上图展示从P1进程创建子进程P2时的物理空间使用状况。通过COW技术，fork()延迟了数据拷贝，根据子进程的实际操作最终可能完全避免数据复制，如：子进程创建后运行一个与当前数据无关的可执行文件。
redis中的COW
某些情况下，我们希望保存redis中的数据，那么只用一个主线程处理请求的redis是怎么在处理请求的同时进行数据持久化的呢？答案当然是依赖COW，具体来说就是依赖系统的fork()函数的COW实现。
redis有两种数据持久化策略：RDB快照和AOF日志。
RDB快照复制某一时刻redis内存中的所有数据保存在文件中，在数据备份程序被触发后redis会调用fork()，这样在轻松获取一份该时刻数据副本的同时，还可以允许主进程继续接受其它请求，读请求不会增加负担，只有写请求到达时才需要真正复制一份数据。RDB快照的一大缺点是可能丢失两次备份时刻之间产生的数据。
AOF日志弥补了RDB快照的不足，将每个收到的写命令都写入日志文件保证数据不会丢失。日志文件会随时间不停增长，为了解决过大的日志文件，redis提供了bgrewriteaof命令对日志进行压缩。bgrewriteaof命令也会调用fork()函数，利用子进程中的数据状态转化成redis命令并保存到新的aof日志中，之后同步父进程中缓存的新写命令，最后用新日志文件替换旧日志文件。
可见，两种数据持久化策略都使用了COW。
jdk中的COW集合
java的基础api中也提供了基于COW的数据集合，但是与前面进行数据备份和降低数据复制开销的目的不同，java中的COW集合更偏向于提供并发能力。
CopyOnWriteArrayList和CopyOnWriteArraySet都是使用在读多写少且数据总量不大的场景下，在保证多线程写的原子性的同时又避免了读的冲突和竞争，使用迭代器的时候也绝对不会抛出ConcurrentModificationException。
在集合内部，利用ReentrantLock同步多个写操作，锁竞争胜利进入同步代码段的程序经过已下几步完成数据修改：
1.复制原始数据
2.修改原始数据
3.将修改后的数据赋给集合数据引用
4.退出同步锁定区域
在写方法执行前和执行中的读操作都是直接取得旧数据的引用，由于迭代器的修改方法被禁用，所以迭代遍历数据的程序总是在使用一份不会改变的数据引用。因为写操作最后修改数据引用的操作是原子的，所以读操作不会错误的得到“部分修改”的数据。
linux内核中有一种叫做RCU(Read-Copy Update)数据共享策略跟COW十分相似，唯一不同在于RCU的新旧数据替换同过特定的回调(callback)机制被动执行，而不是由写操作进程自助完成，有兴趣的同学可以自己研究一下。
总结
copy-on-write是个古老，容易理解且比较高效的策略，可以在数据备份或者读多写少的场景下选择使用。同时它也存在一些先天缺点，数据复制过程中需要双倍的存储空间，如果涉及到IO读取那还会成倍消耗IO资源，使用过程中需要注意控制copy的范围。
有兴趣的同学可以自行阅读相关技术，扩展学习一下优化策略。如：Redirect-On-Write、Copy-On-First-Write、Allocate-On-Flush(also called delayed allocation)、RCU。
